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(54) Transmission burst time indications for power saving 

(57) A method and apparatus are disclosed where- 
by a time-slicing approach to the delivery of packet data 
is enabled. The approach is particularly suited to ena- 
bling power management by mobile terminals where re- 
ceiver demands otherwise place strenuous require- 
ments on an internal power source such as a battery. 
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Description 

[0001] The present invention relates to the content 
delivery utilising Internet Protocol (IP) networking, par- 
ticularly, although not exclusively data networks. 5 
[0002] Wireless IP networks, and particularly mobile 
wireless IP networks typically include a terminal having 
stringent power requirements. Such a mobile terminal 
may be required to operate for lengthy periods on an 
internal source of power. In the case of simplex wireless 
IP networks exemplified by the Digital Video Broadcast 
(DVB) terrestrial (DVB-T) and satellite (DVB-S) net- 
works, typically a large part of the energy requirement 
of a terminal is due to the demands of a receiver nec- 
essary to receive transmissions carrying a range of con- 
tent. 

[0003] It is the case, however, that a user of the ter- 
minal may at an application level, as set out in the well- 
known Open Syslem Interconnect (OSI) model, make a 
selection of particular content from the range of content 
presently received by the terminal. Although such a se- 
lection may take place in a unicast environment, that is 
a one to one transmission, more typically the content is 
distributed in a one to many transmission, that is a mul- 
ticast environment. 

[0004] A well-known mechanism for facilitating the 
delivery of content in a multicast environment is provid- 
ed by the Session Announcement Protocol (SAP), de- 
tails of which are set out in RFC2974 published by the 
Internet Engineering Task Force (IETF repository at ht- 
tp://www.ietf.org) and the Session Description Protocol 
(SDP), details of which are to be found in RFC2327 pub- 
lished by the Internet Engineering Task Force (IETF re- 
pository at http://www.ietf.org). In summary, an Applica- 
tion Programming Interface (API) is provided which fa- 
cilitates communication between applications over an IP 
protocol. The API listens at a particular address for in- 
formation identifying available streams of content, so- 
called services. The information provided at that ad- 
dress is then provided to an application, a browser for 
example, which in turn uses the API to access a selected 
stream by opening a socket at which the selected 
stream can be heard. Typically, the selection of the de- 
sired content is made by a user via the browser, i.e. by 
clicking on a particular link. 

[0005] According to a first aspect of the present inven- 
tion, there is provided a packet data transmission meth- 
od, the method comprising receiving a content stream 
containing packets and dividing said packets into a se- 
quence of sets of packets and for each set of packets 
in said sequence generating a transmission burst, 
wherein a field in each packet of a set includes a value 
indicative of a time offset to the generation of a further 
transmission burst containing a next set of packets in 
the sequence. 

[0006] Such a transmission method facilitates a time- 
slicing approach to the delivery of packet data over IP 
networks, particularly wireless networks such as those 
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now being utilised for the delivery of digital television 
and the like. Such a method is particularly suited to the 
delivery of data including multimedia content to mobile 
clients or terminal over such networks. Preferably, the 
method allows a head-end to receive multiple streams 
of content or services and thereby take advantage of the 
broad bandwidth and high data rates of such networks. 
The method is particularly suitable for use with the IPv6 
protocol which is intended to include within the standard 
header space fields such as a flowjabel field suitable 
for providing the timing and optionally grouping informa- 
tion for a burst. Each burst will contain sufficient infor- 
mation to allow it to be recognised by a receiving client 
(hereinafter a terminal). Typically, the identification is 
provided by an IP address and a flowjabel value con- 
taining at least the time offset. It will be recognised that 
some information pointing towards the IP address or 
some other identifier may be added to the flowjabel val- 
ue so as to identifier a packet and in particular to allow 
it to be associated with a particular content or service 
stream. 

[0007] Preferably the method is applied to the deliv- 
ery of data over a simplex broadcast network such as a 
broadband digital broadcast network. The method may 
be carried out entirely within the network head-end, in 
which case the generation of a value of the time offset 
may be carried out entirely within parameters set by the 
network operator. Alternatively, the content provider 
may apply the method to content before delivery of a 
content stream to the head-end of the transmission net- 
work. 

[0008] Preferably, the method allows the re-transmis- 
sion of packets in so-called copy bursts, that is bursts 
containing substantially the same packets as originally 
transmitted, so-called original bursts. In this transmis- 
sion environment, the offset time held in packets of copy 
bursts will decrease as the burst generation time of the 
next original burst approaches. 
[0009] According to a further aspect of the invention, 
there is provided a packet data reception method, the 
method comprising receiving a plurality of transmission 
bursts, extracting a set of packets from each burst, each 
packet including a first field having a value indicative of 
a sequence of sets of packets and a second field indic- 
ative of a time offset to the generation of a transmission 
burst containing a next set of packets in the sequence, 
analysing each of said extracted packets and identifying 
firstly a packet where a change in said first field to a 
predetermined value is detected and storing this and 
any subsequent packet with the same first field until 
such time as a further change in said first field value is 
detected whereupon reception of transmission bursts is 
suspended for the time offset identified from said sec- 
ond field value. 

[0010] The reception method facilitates the delivery of 
multiple services or content for consumption by a termi- 
nal. The method seeks to facilitate robust error correc- 
tion in that conveniently additional copy bursts may be 
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received to allow replacement of erroneous packets. In 
addition, the burst nature of the transmission method 
coupled with the timing information regarding the deliv- 
ery of original bursts permits power management of the 
terminal functions. Thus, power intensive features of the 
terminal such as the broadband receiver circuitry may 
be powered down during periods where no burst is ex- 
pected. Other power saving opportunities provided by 
the method include suspending processing require- 
ments related to the identification of burst boundaries, 
a burst boundary being the change in the IP address or 
other sequence identifier between packets delivered in 
a stream as extracted from received bursts. 
[001 1] It should be noted that either of the above two 
aspects of the invention may be implemented as soft- 
ware, hardware, or a combination of the two, as would 
be apparent to those skilled in the art. 
[0012] In order to assist in understanding the inven- 
tion, an embodiment thereof will be described by way of 
example and with reference to the accompanying draw- 
ings, in which: 

Figure 1 , is a diagram illustrative of a transmission 
method in accordance with a first aspect of the 
present invention; 

Figure 2, is a diagram showing in more detail a 
transmission channel of the method of Figure 1 ; 
Figure 3, is a diagrammatic view of a terminal op- 
erable in accordance with a method of reception ac- 
cording to a second aspect of the present invention, 
shown receiving the transmission channel of Figure 
2; 

Figures 4a, 4b and 4c, are views illustrative of pack- 
et flows in the terminal of Figure 3; and 
Figure 5 : is a flow chart useful in understanding the 
reception method of Figure 3. 

[0013] Referring to Figure 1 , there is shown a broad- 
band digital broadcast head-end 1 connected to a vari- 
ety of sources 2, 3, 4 of content A, B, C which content 
or service is delivered to the head-end in the form of 
packets 5 of data, these packets having been generated 
in accordance with Version 6 of the Internet Protocol 
(IPv6) details of which may be found in RFC260 pub- 
lished by the Internet Engineering Task Force (IETF) 
and available at www.ietf.org. Thus, each packet In- 
cludes a flowjabel field to facilitate the handling by the 
Internet infrastructure of particular so-called flows of re- 
lated packets. The flowjabel itself forms part of the IPv6 
header and is a 20bit field having a default value of zero. 
Further details of the flowjabel as originally proposed 
may be found in RFC 2460 published by the IETF and 
available at www.ietf.org. Each source of content A, B, 
C is encapsulated by a packet data processor 6 at the 
head end 1 and placed into a transport stream 7 where 
it is multiplexed with the other content similarly encap- 
sulated at the head-end 1 by the packet data processor 
6. As will be described in more detail below, multicast 



and possibly unicast may include a non-zero flowjabel 
field within the IPv6 header. The transport stream 7 fur- 
ther includes packets 9 providing time stamp informa- 
tion and control data identifying content in the stream 7. 

5 Other mechanisms for placing content into the transport 
stream 7 include, data piping, data streaming, and the 
use of data and object carousel. Such mechanisms are 
known, in the case of digital broadcast television, for ex- 
ample, from the Digital Video Broadcast (DVB) Project 

10 which describes one particular broadband digital broad- 
cast solution using MPEG-2 to which the invention is ap- 
plicable. 

[0014] The content can include the delivery of Internet 
services via the transmission channel 18. Such services 

15 may be unicast, in the sense that they are a one to one 
provision of content or multicast in the sense that they 
are a one to many provision of content. In IP terms, a 
multicast address is differentiated from a unicast ad- 
dress by inspecting the most significant byte. A particu- 

20 lar block of IP addresses are dedicated to use by multi- 
cast services namely 224.0.0.0 to 239.255.254.0 using 
the dotted decimal notation known from IPv4. In the 
case of IPv6, further details of which may be found from 
RFC2375 published by the IETF and available for the 

25 time being from www.ietf.org), multicast addresses are 
in the format FFAB where FF is the multicast identifier, 
A indicates whether the address is permanent or tem- 
porary and B provides the scope of the address. Thus, 
where a service is intended to be multicast, the service 

30 must ensure that an address from this block is utilised 
in the destination address portion of each IP packet. 
[0015] Returning to the operation of the head-end 1 , 
the packet data processor 6 having received the 
streams A, B, C of data corresponding to content or a 

35 service 2,3,4 divides each stream of packets into a se- 
quence of discrete sets of packets for transmission at a 
selected time. The sets of packets 1 9 which have been 
divided in this manner are passed to a burst generator 
20 which generates a high-bandwidth low-duration orig- 

40 jnal burst 22 for transmission by a transmitter portion 21 
of the head-end 1 . Each original burst 22 contains data 
from a single IP address corresponding to the content 
or a service 2,3,4. The packet data processor 6 is further 
operable to generate a copy 23 of a set of packets which 

« together make up a particular original burst 22 when so 
instructed by a controller 24. Again, copy set of packets 
23 contains data from a single IP address corresponding 
to the content or service 2,3,4. This copy 23 of a set of 
packets is then passed to the burst generator 20 which, 

so as before, generates a high -bandwidth low-duration 
burst for re-transmission as a copy burst 25 by the trans- 
mitter portion 21 of the head end 1 . The copy bursts 25 
are also transmitted at selected times which times are 
arranged such that bursts, whether an original or a copy 

55 and containing packets from a particular stream of data 
corresponding to content or service 2,3,4 do not collide 
either with another burst containing packets in that 
stream or another stream currently being transmitted by 
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the head-end 1 . 
[0016] With reference to Figure 2, in order to facilitate 
reception of a particular service or content 2,3,4 in such 
a transmission channel 18 where multiple bursts con- 
taining the same packets are transmitted, namely an 5 
original burst 22 and one or more copy bursts 25, in ad- 
dition to dividing each packet stream into a sequence of 
discrete sets of packets, the packet data processor 6 
also introduces a non-zero value into a flowjabel field 
of every packet in each set which ultimately comprise a 
burst, whether an original or a copy burst 22,25. The 
value introduced into the flowjabel field of each packet 
in a set from which a burst is formed, is a time offset 26 
which provides the time interval from the start of the 
burst which includes that packet to the start of the next 
original burst in the sequence of bursts making up that 
particular content or service. Where a service is discon- 
tinued, there will be no further bursts having the same 
IP address, at least until a pre-determined timeout or 
guard interval has expired before a new service may 
start from that address. In this situation, the offset will 
be set to a maximum value or another predetermined 
value indicative of the service being discontinued. 
[0017] The channel 18 is received by a set of termi- 
nals which in the case of a satellite system fall under the 
satellite footprint, whilst in the case of a terrestrial sys- 
tem, the receiving terminals fall within areas of transmis- 
sion coverage of a transmitter network. Each terminal, 
which includes a mobile terminal 10, is typically under 
the control of a user at least as far as sh e is able to select 
particular content from that currently being transmitted 
in the transport stream 7. The mobile terminal 1 0 shown 
in Figure 3, includes an internal power supply 12, such 
as a rechargeable battery supplying power to a control- 
ler 13, user interface 14 and a receiver 15. The terminal 
10 also incorporates both memory 16 and storage 17 
necessary to execute applications and consume con- 
tent. A fixed terminal may, of course, dispense with the 
requirement for a internal source of power. 
[0018] The receiver 15, as has been mentioned, has 
a proportionally larger power consumption than the oth- 
er components of the terminal 10. In order to minimise 
drain on the internal power supply 12, the receiver 15 
may be switched on and off in response to instructions 
received from the controller 13. The receiver 1 5 , when 
in operation, receives the channel 1 8 over the air, in the 
case of satellite or terrestrial transmission. The opera- 
tion of the receiver 15 is such that over a predetermined 
and possibly variable service period, say 60 seconds, 
the receiver 15 is capable of being switched into oper- 
ation for one or more periods of time determined by the 
accuracy of a receiver clock forming part of the controller 
1 3. For example, where the receiver clock accuracy can 
be maintained at 234 milliseconds, each period may last 
for 234.375 milliseconds there being 256 such periods 
within the aforementioned 60 second service period. 
[001 9] The controller 1 3 is operable to switch the re- 
ceiver 15 between on and off states in response to the 
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offset determined from the flowjabel field as further de- 
scribed below with additional reference to Figures 4 and 
5. 

[0020] Thus, the receiver 15 is operable to receive 
bursts transmitted by the head-end 1. Of course, the 
head-end 1 will be transmitting bursts corresponding to 
a range of services and content 2,3,4. The receiver 15 
extracts packets from each burst 22,25 it receives and 
the resulting sets of packets 19,23 are placed into a 
stream 27 which is analysed by the controller 13. The 
controller 13 analyses packets 22,25 in the stream 27 
by determining the IP address and flowjabel field val- 
ues from the header of each packet. The controller 13 
seeks 100 to identify a change from one IP multicast 
address to another IP multicast address which corre- 
sponds to content or a service which the terminal 10 
wishes to consume. A change in IP address identifies a 
burst boundary, that is the beginning of a set of packets 
in the stream 27, which have been placed in the same 
burst 19,23 at the head-end 1 . 

[0021] Thus, where a boundary is identified 101, the 
controller determines whether the IP address of the an- 
other IP multicast address corresponds to an address 
of content or a service to be consumed by the terminal 
10. If the another IP multicast address does indeed cor- 
respond then the controller, having identified such a 
boundary, further determines the flowjabel field value 
in each packet header This value will remain constant 
for each packet forming part of the same burst because 
it is a value indicative of the time offset 26 to the next 
original burst in the sequence of bursts making up that 
particular service 2,3,4. The controller 13 thereafter 
stores each packet it identifies as having the same IP 
address and offset value 26. It will be recognised that 
the duration of each burst 22,25 (although not shown as 
such on Figure 2 in particular) may be varied and cor- 
respondingly the number of packets contained in a burst 
need not be constant as the controller 13 will only stop 
storing packets from a burst once a change is detected 
in the IP address and/or flowjabel value. Once such a 
change has been detected, the controller 1 3 initiates an 
error check 1 03 of the stored packets. Depending on the 
outcome of this error check the controller will take one 
of two steps. Where errors are detected, the controller 
marks those packets containing errors and continues to 
analyse the stream of packets 27 being extracted by the 
receiver 15 for a burst boundary indicative of a copy 
burst 25 corresponding to the burst 22,25 which deliv- 
ered the packets presently in storage, namely the con- 
troller again seeks to identify a burst having the same 
IP address but note that the time offset 26 will be re- 
duced. Providing such a burst exists and is detected by 
the controller 1 3, the controller 13 will store the packets 
from the copy burst and carry out an error analysis be- 
fore replacing any bad packets in the first received burst 
with packets from the copy burst. Such a process will 
be repeated until the time-offset 26 has expired in which 
case a new original burst having the same IP address 
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should be detected unless the service is discontinued. 
[0022] In a second non-illustrated variant, rather than 
replace individual packets, the entire set of packets from 
the first burst is discarded and replaced by the packets 
extracted from a copy burst. This process will be repeat- 
ed until either all packet errors have been corrected or 
the next original burst in the sequence is received by the 
terminal in which case the packets from the last original 
burst may either be flushed from storage or passed with 
or without the marked up bad packets to a terminal ap- 
plication for consumption. 

[0023] Where all the packet errors have been correct- 
ed or alternatively the time offset is about to expire, then 
the process moves to the second outcome namely the 
process followed where the error check 103 of the 
stored packets reveals no errors. Thus, the packets are 
marked as valid by the controller 1 3 and are passed for 
consumption at the application level by the terminal 1 0. 
However it is conceivable that in some circumstances, 
it may not be desirable to forward partial bursts, that is 
bursts containing some errors, for consumption by the 
terminal. In which case, the controller will simply drop 
the partial burst. At the same time, the controller 13 in- 
structs the receiver 15 to shut down such that no more 
packets are extracted from incoming bursts 22,25 in the 
channel 1 8 with the result shown in Figure 4b that no 
packet stream 27 is delivered to the controller 13. The 
controller 13 however remains active and ready to in- 
struct the receiver 1 5 to power up in anticipation of re- 
ceiving (Figure 4c) the next original burst 22 in the se- 
quence of bursts making up the particular content or 
service 2,3,4. The time period for which the receiver is 
shut down is determined, of course, from the flowjabel 
field value namely the offset 26 derived from those valid 
packets extracted from the current burst. The controller 
13 utilises the offset 26 to determine the time at which 
the receiver should be powered up ready to receive the 
next original burst in the sequence of packets making 
up the content or service. It may well be the case that 
the receiver 15 should be powered up some time in ad- 
vance of the expiry of the time offset period to ensure 
that packets can be reliably extracted from the incoming 
channel 18. 

[0024] By way of further explanation, where con- 
sumption of different content is desired, the controller 
13 is simply provided with the IP address of the content 
or service 2,3,4 which is now desired. As will be appar- 
ent from Figure 4c in particular, the receiver 1 5 will be 
extracting packets from a number of bursts 22,25 con- 
taining packets of several content or service streams A, 
B,C delivered to the head-end 1 from their respective 
sources 2,3,4. It may well also be the case that the re- 
ceiver 15 is powered off as a consequence of the last 
offset value 26 derived by the controller 1 3. In this event, 
the controller 1 3 may immediately power up the receiver 
1 5 following the receipt of instructions to consume a new 
service or content. Alternatively, the receiver 1 5 may re- 
main powered down until the time at which the controller 



causes it to power up to commence receiving the next 
original burst of what was the previously desired con- 
tent. In this case, the controller will, rather than identify 
and store packets corresponding to the previously de- 
5 sired content, instead continue analysing the packet 
flow until a burst boundary is detected for a burst 22,25 
containing the newly selected content or service pack- 
ets 19,23. 



Claims 

1. A packet data transmission method, the method 
comprising receiving a content in the form of pack- 
's ets and dividing said packets into a sequence of 
sets of packets and for each set of packets in said 
sequence generating a transmission burst, wherein 
a field in each packet of a set includes a value in- 
dicative of a time offset to the generation of a further 
transmission burst containing a next set of packets 
in the sequence. 

A method as claimed in Claim 1 , wherein the se- 
quence is such that sets of packets are generated 
as transmission bursts in the order that they are re- 
ceived in the content stream. 

A method as claimed in Claim 1 or Claim 2, wherein 
separate sequences of sets of packets are gener- 
ated as transmission bursts for respective ones of 
a plurality of received content streams. 

A method as claimed in any one of Claims 1 to 3, 
wherein said field additionally contains a value in- 
dicative of a sequence of sets of packets. 

A method as claimed in any one of Claims 1 to 3, 
wherein said packet includes a field having a value 
indicative of a sequence of sets of packets. 

A method as claimed in Claim 4 or Claim 5, wherein 
said value indicative of a sequence of sets of pack- 
ets is a multicast address. 

A method as claimed in any one of Claims 1 to 6, 
wherein the time offset value of a packet is calcu- 
lated utilising a transmission generation time of the 
burst which includes that packet and the transmis- 
sion generation start time of the transmission burst 
containing the next set of packets in the sequence. 

A method as claimed in any one of Claims 1 to 7, 
wherein the packets are received in a content 
stream. 

9. A computer program comprising executable code 
for execution when loaded on a computer, wherein 
the computer is operable in accordance with said 
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code to carry out the method according to any one 
of Claims 1 to 8. 

10. A program as claimed in Claim 9, stored in a com- 
puter readable medium. 

11. A head-end apparatus for packet data transmis- 
sion, wherein the apparatus is operable in accord- 
ance with any one of Claims 1 to 8. 

12. A packet data reception method, the method com- 
prising receiving a plurality of transmission bursts, 
extracting a set of packets from each burst, each 
packet including a first field having a value indica- 
tive of a sequence of sets of packets and a second 
field indicative of a time offset to the generation of 
a transmission burst containing a next set of pack- 
ets in the sequence, analysing each of said extract- 
ed packets and identifying firstly a packet where a 
change in said first field to a predetermined value 
is detected and storing this and any subsequent 
packet with the same first field until such time as a 
further change in said first field value is detected 
whereupon reception of transmission bursts is sus- 
pended for the time offset identified from said sec- 
ond field value. 

13. A method as claimed in Claim 12, wherein the sus- 
pension of reception is conditional upon the detec- 
tion of no errors in the stored packets such that 
where an error exists in said stored packets, the 
analysis of said extracted packets is continued for 
packets having a first field corresponding to said 
predetermined value. 

14. A method as claimed in Claim 13, wherein said 
stored packets are replaced by one or more packets 
obtained from said continued analysis. 

1 5. A method as claimed in any one of Claims 1 2 to 1 4, 
wherein at least one of the following steps of extrac- 
tion, analysis and storage is suspended together 
with said reception during said time offset. 

1 6. A method as claimed in any one of Claimsl 2 to 1 5, 
wherein said field value indicative of a sequence of 
sets of packets is a multicast address. 

1 7. A method as claimed in any o ne of Claims 1 2 to 1 6, 
wherein the time offset value of a packet corre- 
sponds to the time difference calculated from a 
transmission generation time of the burst which in- 
cludes that packet and the transmission generation 
start time of the transmission burst containing the 
next set of packets in the sequence. 

18. A computer program comprising executable code 
for execution when loaded on a computer, wherein 



the computer is operable in accordance with said 
code to carry out the method according to any one 
of Claims 12 to 17. 

5 19. A program as claimed in Claim 18, stored in a com- 
puter readable medium. 

20. A terminal for packet data reception, wherein the 
apparatus is operable in accordance with any one 
of Claims 12 to 19. 
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(54) Transmission burst time indications for power saving 

(57) A method and apparatus are disclosed where- 
by data is transmitted in sequences, these sequences 
are transmitted in bursts. 

Together with a sequence, a time indication is transmit- 
ted indicating the time offset of the following sequence. 
Thereby, a receiver is enabled to change to standby or 
sleep mode between two bursts in order to save energy. 
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FIG. 4a 
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